I do not see test with pydantic 1.x, Should be here: if hasattr(cls, "model_computed_fields")?

As it may happen in the middle of for loop

I do not fully understand. When we need to emit a signal. This comment still statement that self._primary_changes are only fields changed by direct assignment.
And documentation of https://docs.pydantic.dev/2.0/usage/computed_fields/ do not mention the assigment of this property.

yeah, i wasn't entirely clear on the _primary_changes, and _changes_queue attributes here. So maybe I did it wrong. we need to emit a signal here when a non-field attribute changes, provided that some other evented field lists that attribute as one of its "dependents". So, in the example provided by the original requester:

from psygnal import EventedModel
from pydantic import computed_field, PrivateAttr

class MyModel(EventedModel):
    _items_dict: dict[str, int] = PrivateAttr(default_factory=dict)

    @computed_field
    def item_names(self) -> list[int]:
        return list(self._items_dict.keys())

    def add_item(self, name: str, value: int) -> None:
        # this next assignment should trigger the emission of `self.events.item_names`
        # because `_items_dict` was listed as a field_dependency of `item_names`
        self._items_dict = {**self._items_dict, name: value}

    class Config:
        field_dependencies = {"item_names": ["_items_dict"]}

if I did that incorrectly (or stupidly) with the existing _primary_changes/_changes_queue pattern let me know

i think this might be the first case where the "primary change" is to a non-evented attribute (_items_dict)... and so it didn't quite fit into the existing pattern. It's the first case where a _primary_change isn't actually able to itself be evented

Hm.

Maybe we should add a dummy emiter (callback that do nothing, and raises an exception on connection) for private attributes that are listed in field_dependencies? Then we will move the complexity from setattr to constructor call?

that's worth trying, lemme see how it goes